Cross-Site Scripting (XSS) đã được mệnh danh là "lỗ hổng muôn thuở". Từ đơn giản chỉ hiển thị cửa sổ alert đến các tấn công tinh vi, XSS không ngừng tiến hóa theo thời gian. Nhưng bạn đã bao giờ tự hỏi: 

liệu một lỗ hổng XSS có thể dẫn đến chiếm quyền điều khiển hoàn toàn hệ thống không?

Blog này sẽ đưa bạn khám phá kỹ thuật tấn công XSS tiên tiến, cùng các vector vượt khỏi giới hạn trình duyệt để thực thi mã từ xa (RCE), đặc biệt trên các ứng dụng Electron. Đây không chỉ là kiến thức lý thuyết mà còn là bài học thực chiến cho cả pentester lẫn developer.

XSS tiên tiến và các vector hiện đại

 - Những kỹ thuật bypass bộ lọc mới nhất và cách khai thác ngữ cảnh đa tầng

 - Chiến lược nâng cấp một cuộc tấn công XSS thành thực thi mã từ xa

 - Tại sao ứng dụng desktop dựa trên web đặc biệt dễ tổn thương

 - Best practices cho developer và tester

Đừng dừng lại ở việc chỉ hiểu XSS cơ bản - hãy hiểu cơ chế bên trong để bảo vệ ứng dụng của bạn trước những mối đe dọa ngày càng phức tạp.

XSS Tiên Tiến và Các Vector Hiện Đại 🔍

Vượt xa những payload đơn giản như 

, XSS hiện đại khai thác sự phức tạp của HTML, CSS, và JavaScript trong nhiều ngữ cảnh khác nhau.

Một trong những kỹ thuật tiên tiến nhất là 

 - nơi các payload được thiết kế để vượt qua nhiều lớp bảo vệ bằng cách chuyển đổi giữa các ngữ cảnh HTML, JavaScript, và CSS. Chẳng hạn, một chuỗi vô hại trong ngữ cảnh HTML có thể trở nên nguy hiểm khi được xử lý trong ngữ cảnh JavaScript:

<div data-user="normal"></div>  <div data-user=""></div><script>alert(1)</script>"></div>

Kỹ thuật làm rối mã (obfuscation) hiện đại

Các bộ lọc XSS ngày càng thông minh, nhưng kẻ tấn công cũng vậy. Họ sử dụng 

 tinh vi để qua mặt WAF và sanitizer:

: Kết hợp URL encoding, HTML encoding, và JavaScript encoding để tạo ra các payload mà bộ lọc khó nhận diện nhưng trình duyệt vẫn hiểu được

: Chèn các ký tự không hiển thị vào payload để phá vỡ mẫu nhận dạng của bộ lọc

: Tạo mã JavaScript chỉ sử dụng các ký tự đặc biệt như 

Một ví dụ tinh vi là cách khai thác chức năng automatic sanitization của DOMPurify. Nhà nghiên cứu Gareth Heyes đã tìm ra cách sử dụng 

 để bypass DOMPurify bằng payload chèn HTML qua các thẻ 

Trình duyệt xử lý đoạn mã này khác với cách DOMPurify phân tích, tạo ra lỗ hổng trong quá trình "giao lưu" giữa các namespace HTML và SVG/MathML.

 là kỹ thuật tinh tế cho phép kẻ tấn công ghi đè các thuộc tính hoặc phương thức JavaScript thông qua các phần tử HTML. Ví dụ:

Payload này có thể ghi đè thuộc tính 

 của đối tượng form, khiến script chạy trên trang không thể duyệt qua attributes theo cách bình thường, từ đó làm cho các cơ chế lọc dựa trên DOM thất bại.

Nhiều hệ thống lọc chỉ tập trung vào việc tìm và chặn các pattern nguy hiểm rõ ràng như 

, nhưng bỏ qua các kỹ thuật DOM clobbering tinh vi này.

Từ XSS Đến RCE - Con Đường Nâng Cấp Tấn Công 🚀

Thông thường, XSS bị giới hạn trong phạm vi trình duyệt, nhưng có nhiều cách để nâng cấp từ XSS đến RCE (Remote Code Execution) - vượt ra khỏi "hộp cát" của trình duyệt và thực thi mã trên hệ thống.

Trình duyệt web đôi khi có lỗ hổng cho phép kẻ tấn công thoát khỏi "hộp cát" và truy cập hệ thống. Một khi đã có XSS, kẻ tấn công có thể:

Tận dụng lỗ hổng zero-day trong rendering engine

Khai thác lỗi trong các plugin như Flash (trước đây) hoặc Java

Lợi dụng lỗi trong quá trình xử lý PDF hoặc media

Ví dụ thực tế: Năm 2019, lỗ hổng CVE-2019-5786 trong Chrome V8 JavaScript engine đã cho phép kẻ tấn công thực thi mã từ xa. Kết hợp với XSS, điều này tạo ra mối đe dọa nghiêm trọng.

2. Đánh cắp cookie và session để tấn công server-side

Một trong những cách gián tiếp để XSS dẫn đến RCE là thông qua việc đánh cắp cookie admin hoặc session:

Tấn công XSS để lấy cookie của người quản trị

Sử dụng cookie này để truy cập vào bảng quản trị

Nếu bảng quản trị có chức năng upload file hoặc thực thi mã từ xa, kẻ tấn công có thể tận dụng để thực hiện RCE

Tại một số tổ chức, quản trị viên có quyền thực thi các tác vụ trên server như export data, backup, hoặc thậm chí là chạy các lệnh shell thông qua web interface. Chiếm quyền quản trị viên có thể dẫn đến quyền kiểm soát hệ thống hoặc cơ sở dữ liệu.

3. Khai thác các chức năng hiện có

Nhiều ứng dụng web có chức năng tương tác với hệ thống file hoặc thực thi lệnh, mà thường được giới hạn bởi phân quyền người dùng. XSS có thể cho phép:

Thao túng các tham số API để thực thi lệnh bên ngoài phạm vi cho phép

Xâm nhập các chức năng nhập/xuất dữ liệu để ghi file độc hại

Khai thác các endpoint nội bộ không được bảo vệ đúng cách

Một ví dụ điển hình là nhiều ứng dụng có chức năng export data sang CSV hoặc Excel. Bằng cách chèn macro độc hại vào dữ liệu, kẻ tấn công có thể tạo file độc hại khi admin xuất dữ liệu.

Electron và Hiểm Họa Đặc Biệt ⚠️

Electron là framework phổ biến cho phép xây dựng ứng dụng desktop dựa trên công nghệ web (HTML, CSS, JavaScript). Nhiều ứng dụng phổ biến như VS Code, Slack, Discord, và Teams đều được xây dựng trên Electron.

Tại sao Electron đặc biệt dễ bị tổn thương?

Electron có một đặc điểm khiến nó trở thành mục tiêu hấp dẫn: 

mặc định, nó chạy trong môi trường có quyền truy cập hệ thống cao hơn so với trình duyệt thông thường

: Ứng dụng Electron mặc định có thể đọc/ghi file trên hệ thống

: Electron tích hợp Node.js, cho phép truy cập đến hầu hết các module Node

Để từ XSS dẫn đến RCE trong Electron, cần khai thác ba thành phần chính:

 - có thể từ các input không được sanitize, hoặc content injection

 - vượt qua cơ chế phân chia context giữa renderer và Node

 - sử dụng Node.js API để thực thi lệnh trên hệ thống

Một kỹ thuật phổ biến là khai thác cấu hình 

 được bật mặc định, cho phép JavaScript chạy trong renderer process trực tiếp truy cập Node.js API.

Một ví dụ thực tế về khai thác này xảy ra với ứng dụng Slack vào năm 2020 (CVE-2020-27888). Lỗ hổng XSS trong Slack Desktop cho phép kẻ tấn công thực thi mã từ xa bằng cách:

// Một khi có XSS trong ứng dụng Electron với nodeIntegration bật const { exec } = require('child_process'); // Thực thi lệnh trên hệ thống exec('calc.exe', (error, stdout, stderr) => { // Mã độc đã được thực thi });

 bị tắt, các nhà nghiên cứu đã tìm ra các kỹ thuật bypass, ví dụ thông qua preload script hay contextBridge API.

Những phương thức tấn công phổ biến trong Electron

Nạp lại trang với cấu hình khác

: Khai thác các giao thức đã đăng ký như 

: Tìm cách vượt qua phân chia giữa các context khác nhau

Một ví dụ khác về CVE-2023-32309 trong Microsoft Teams (dựa trên Electron), cho phép kẻ tấn công thực hiện tấn công XSS thông qua URL handler, dẫn đến thực thi mã với quyền của người dùng.

Kết hợp những hiểu biết sâu sắc về bảo mật web với kỹ năng pentest ứng dụng desktop là điều bắt buộc để tìm và ngăn chặn các lỗ hổng này. Đó chính là lý do tại sao khóa học 

 của CyberJutsu chú trọng không chỉ vào kỹ thuật tấn công cơ bản mà còn đào sâu vào các kịch bản tấn công phức tạp như XSS to RCE, giúp học viên xây dựng tư duy bảo mật toàn diện.

Case Study Thực Tế: Khai Thác XSS Dẫn Đến RCE 📑

Để hiểu rõ hơn về cách thức XSS tiến hóa thành RCE trong thực tế, hãy phân tích một số case study đã được công bố. Các trường hợp này cho thấy cách kẻ tấn công tận dụng nhiều lỗ hổng kết hợp để đạt được quyền thực thi mã trên máy người dùng.

Case Study 1: Discord - XSS Trên Vimeo Dẫn Đến RCE

Discord là nền tảng giao tiếp phổ biến được xây dựng trên Electron, kết hợp Chromium và Node.js. Năm 2021, các nhà nghiên cứu an ninh đã tìm thấy một chuỗi tấn công phức tạp:

: Nhà nghiên cứu khai thác lỗ hổng XSS trong video Vimeo được nhúng vào Discord. Discord cho phép 'unsafe-inline' trong CSP của mình, tạo điều kiện cho kẻ tấn công chèn JavaScript.

: Sau khi có XSS, họ bypass sandbox bằng cách mở cửa sổ mới thông qua sự kiện "new-window", vì Discord không hạn chế đủ việc xử lý sự kiện này.

: Cuối cùng, họ khai thác lỗ hổng trong V8 JavaScript engine của Chromium để thoát khỏi sandbox và thực thi mã trên máy nạn nhân, đến mức có thể mở ứng dụng Calculator.

Điều đáng chú ý là chuỗi tấn công này không cần nodeIntegration bật, cho thấy các ứng dụng Electron có thể bị xâm phạm ngay cả khi tuân thủ nhiều khuyến nghị bảo mật.

Case Study 2: Discord - XSS Trên Sketchfab Bypass Navigation Restrictions

Một case study khác về Discord (2020) cho thấy cách kẻ tấn công có thể khai thác XSS từ nội dung bên thứ ba:

: Nhà nghiên cứu phát hiện Discord thiếu 

, cho phép JavaScript từ trang web tương tác với mã Electron.

: Họ phát hiện XSS trong Sketchfab (nền tảng 3D) được nhúng trong Discord, thông qua URL OGP (Open Graph Protocol).

: Bằng cách khai thác lỗ hổng CVE-2020-15174 trong Electron, họ bỏ qua hạn chế điều hướng vì Discord không phát ra sự kiện "will-navigate" cho điều hướng cross-origin.

: Cuối cùng, họ thực thi mã từ xa và nhận phần thưởng $5,000 từ Discord và $300 từ Sketchfab.

Chuỗi tấn công này minh họa cách XSS từ nội dung bên thứ ba có thể dẫn đến RCE, đặc biệt khi ứng dụng cho phép nhúng nội dung từ các nguồn khác.

Case Study 3: PoC Khai Thác Ứng Dụng Notable Thông Qua Markdown

Notable là ứng dụng ghi chú dựa trên Markdown sử dụng Electron. Vào năm 2020, một lỗ hổng nghiêm trọng (CVE-2020-16608) được phát hiện:

: Ứng dụng không xử lý đúng nội dung Markdown từ người dùng, cho phép chèn mã HTML độc hại.

: Thiết lập Electron của Notable để nodeIntegration bật, cho phép truy cập đến các API Node.js.

: Một liên kết đơn giản trong Markdown như: 

[Liên kết vô hại](javascript:require('child_process').exec('calc')) 

Là đủ để mở Calculator trên Windows khi người dùng nhấp vào.

Trường hợp này đặc biệt nguy hiểm vì nó chỉ yêu cầu một XSS đơn giản trong tài liệu Markdown - một nơi người dùng thường không nghi ngờ sẽ chứa mã độc.

Bài viết Medium về Notable CVE-2020-16608

Case Study 4: Trình Duyệt Steam (CEF) Và Chuỗi Tấn Công RCE

Steam không sử dụng Electron mà dùng CEF (Chromium Embedded Framework), nhưng vẫn dễ bị tấn công tương tự. Vào tháng 6/2024, các nhà nghiên cứu đã phát hiện nhiều chuỗi RCE:

Chuỗi tấn công #1 - Khai thác SteamClient

 trong trang ngoài bằng cách sử dụng 

 để tải URL với bất kỳ giao thức nào (file://, chrome://)

Tag: XSS to RCE